# Чистый код

## Описание

Чистый код - это код, который легко читать, поддерживать, расширять и тестировать.

Тимлид отвечает за поддержание кодовой базы в чистоте и борется с энтропией в проекте, объясняет команде и менеджеру долгосрочную выгоду от чистого кода.

Тимлид помогает команде освоить принципы написания чистого кода и практики поддержания чистоты - например, правило бойскаута и отсутствие ["разбитых окон"](https://www.artima.com/intv/fixit.html).

## Почему ветка важна?

Для менеджера:

- Уменьшается время на доработку и исправление продукта с чистым кодом
- Разработчики лучше понимают объем необходимых изменений и дают более точные оценки задачам
- Снижается выгорание разработчиков от постоянной работы с легаси и спагетти-кодом

Для разработчика:

- Чистый код легко читать и изменять, проще судить об эффекте изменений
- При изменении чистого кода возникает меньше регрессионных багов
- Чистый код легко тестировать

## Что будет, если её не делать?

- Появляются компоненты с низким качеством кода и большим количеством багов, с которыми никто не хочет работать и нести ответственность за качество
- Изменение функционала становится болью для разработчиков - сложно найти подходящее место для изменения, оценить его влияние изменения на систему в целом, исправить возникшие баги
- Возникает эффект разбитых окон - качество кода продолжает ухудшаться, отсутствует мотивация к улучшению, длинные методы продолжают расти с каждым изменением - "тут хуже уже не будет"

## На кого может быть делегирована?

Тимлид уровнем ниже, старшие и ведущие разработчики

## Примеры поведения

### Примеры плохого поведения

- В команде нет установленных критериев чистоты кода и контроля за его качеством, любой код уходит в production "как есть"
- Разработчики следуют разным форматам и практикам, у проекта отсутствует общий стиль кода
- В проекте отсутствует линтер для автоматизации проверки кода на соответствие общему стилю, встроенный в процесс сборки и ревью
- Отсутствует время на возврат технического долга после осознанного написания грязного кода с целью успеть к дедлайну, принятые на скорую руку решения расходятся по проекту
- В команде не производится обмен опытом, дублируется код для решения одной и той же проблемы

### Примеры хорошего поведения

- Все разработчики в команде понимают критерии чистого кода и следуют правилу бойскаута - после изменения кода оставляют его в состоянии лучше, чем был
- В процесс сборки и ревью встроен линтер для автоматизации проверки кода на соответствие общему стилю
- Возврат технического долга планируется сразу после дедлайна критичной по срокам фичи с грязным кодом
- Команда регулярно синхронизируется для обсуждения внесённых изменений, разработчики используют уже существующий в проекте код для достижения цели

## Способы прокачки

Для тимлида:

- Выстроить процесс code review
- Разбирать с командой примеры плохого и хорошего кода, подсказывать как применить best practices
- Планировать рефакторинг для возврата вынужденного технического долга

Для разработчика:

- Изучить приёмы [работы с легаси-кодом](https://www.amazon.com/Working-Effectively-Legacy-Michael-Feathers/dp/0131177052)
- Изучить [набор принципов SOLID](https://en.wikipedia.org/wiki/SOLID)
- Попробовать парное программирование с опытным коллегой

## Консультации

- [Telegram-чат TL Bootcamp](https://tlinks.run/tlbootcamp)

## Теория

### Книги

- [Clean Code: A Handbook of Agile Software Craftsmanship, Robert C. Martin, 2008](https://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882)
- [Working Effectively with Legacy Code, Michael Feathers, 2004](https://www.amazon.com/Working-Effectively-Legacy-Michael-Feathers/dp/0131177052)
